Description

The primary focus of this PR was the conversion of form workflows (used within drawers) to the Dynamic Forms system. This migration enabled native reCaptcha implementation, centralized error handling, and the automated use of default values during editing.

Related Ticket #2238 (General ticket about refactoring)

1. Verification Request (VR) - Related Ticket #2107 (Just about the bug)

• Dynamic Source Management: Implemented a new editing logic using a new field in DynamicInput. The primary source of the VR is now immutable to preserve data origin, while additional sources can be freely added or removed.
• Conditional Validation: Leveraged a new functionality to disable specific inputs for fields that do not allow editing within the VR workflow. When an input is disabled, its validation is ignored, ensuring the submission occurs only with permitted values.
• Code Optimization: The refactoring of the edit form aimed to reduce the manual complexity of handling error states, validation, and reCaptcha integration.

2. Namespaces - Related Ticket #2237 (Just about the bug)

• Slug Consistency: Fixed the slug generation logic when editing Namespaces. The system now correctly uses the new name to shape the URL, preventing discrepancies between the display name and its link.
• Role Synchronization: Updated the updateNameSpaceUsers function to ensure user consistency. The system now identifies the old name in the namespace array, removes it, and inserts the new value, preventing duplicate records during name changes.

3. Badges

• Migration to Dynamic Form: Complete conversion of the Badges and Namespaces workflows to the dynamic system. For Badges, a new Image Upload field was developed in DynamicInput, with image validation integrated into the submission process.
• SharedFormFooter Flexibility: The global footer component was updated to support hiding the "Cancel" button and adding extra buttons. This global improvement was applied to the Namespace workflow to accommodate the "Send update via email" button.
• Global Standardization: The migration to the dynamic form lifecycle now ensures standardized validation feedback and error handling across all components consuming this structure.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Existing feature enhancement (non-breaking change which modifies existing functionality)

Testing

• Full Workflows (Creation and Editing): Test the complete creation and editing cycle for Verification Requests, Namespaces, and Badges, ensuring reCaptcha is requested and validated successfully.
• Namespaces (Slug & Roles): Edit a namespace name and verify that the slug updated correctly and that the user does not have duplicate namespaces in their profile.
• Verification Request (Sources): Validate that the first source is blocked for deletion and that adding/removing new sources works via Dynamic Input.
• Badges (Upload): Test the new image upload field, verifying that validation prevents submission in case of errors.
• SharedFormFooter: Verify in the Namespace workflow if the extra email button appears correctly and if the conditional button behavior works as expected.

Evidence

Detailed evidence, including screenshots and screen recordings of the new flows, can be found at the link below:

👉 View Evidence on Notion

Developer Checklist

General

• Code is appropriately commented, particularly in hard-to-understand areas
• Repository documentation has been updated (Readme.md) with additional steps required for a local environment setup.
• No console.log or related logging is added.
• No code is repeated/duplicated in violation of DRY. The exception to this is for new (MVP/Prototype) functionality where the abstraction layer may not be clear (comments should be added to explain the violation of DRY in these scenarios).
• Documented with TSDoc all library and controller new functions

Frontend Changes

• No new styling is added through CSS files (Unless it's a bugfix/hotfix)
• All types are added correctly

Backend Changes

• All endpoints are appropriately secured with Middleware authentication
• All new endpoints have a interface schema defined

Tests

• All existing unit and end to end tests pass across all services
• Unit and end to end tests have been added to ensure backend APIs behave as expected

Test IDs

• Include the test ID when adding new tasks or components.
• Check that test IDs are present in the modified components.

Merge Request Review Checklist

• An issue is linked to this PR and these changes meet the requirements outlined in the linked issue(s)
• High risk and core workflows have been tested and verified in a local environment.
• Enhancements or opportunities to improve performance, stability, security or code readability have been noted and documented in Project do Github issues if not being addressed.
• Any dependent changes have been merged and published in downstream modules
• Changes to multiple services can be deployed in parallel and independently. If not, changes should be broken out into separate merge requests and deployed in order.